本系列目錄 《來做個網路瀏覽器吧！》文章列表

前言

看到一篇很神奇的論文：Caching Doesn’t Improve Mobile Web Performance (Much)，翻譯一下就是，在手機上的瀏覽器採用 Cache 機制並不會讓瀏覽器快多少。事實上是會快一點，但真的只是一點點。

一個包含 Google 工程師的研究團隊發現，Cache 機制在桌面上瀏覽器去以讓速度進步 34 %，但在手機上瀏覽器卻僅僅 13 %。這很奇怪，真的很怪，Google 工程師心想「我們家的 Chrome 應該大小通吃啊？!」回顧一下我們在「為什麼手機上網速度比較慢呢？」這篇文章中提到的，網路延遲以及載入相關檔案會使得使用者感受到瀏覽器很卡。而 Cache 是指瀏覽器將一些資源暫存起來，下次要用時就不需要再下載，理論上應該很快啊？尤其網路是關鍵的的時候更該是如此？

接下來我們來看看這篇論文做了甚麼研究來解釋這個神奇的現象！

註: 以下的圖片皆來自原始論文

一些先備知識

瀏覽器的流程圖我們已經看很多了，不過今天的多了一個 cache

載下來的資源會存在 cache 以便不時之需。

再來我們看一下載入資源的時程圖

這邊我們定義兩個名詞 Page Load Time（單頁載入時間）和 Critical Path（關鍵路徑）。
所謂單頁載入時間就是當瀏覽器開始下載到一切就緒的時間，通常就是從開始跑到 js 的 onload 被呼叫的時候。
關鍵路徑則是載入過程中所需要的最長路徑。怎麼說呢？因為不相干的東西可以同時一起載，但是如果有關聯性的東西，就必然會有先後順序了，可能是Ａ裡面呼叫Ｂ，Ｂ再乎叫Ｃ。

我們將會使用關鍵路徑分析（critical path analysis）非常適合用在平行化處理的服務上，瀏覽器就非常適合，任何不是關鍵路徑上的優化都不會讓單頁載入時間變短，如同上圖中 png 的時間變短也不會影響關鍵路徑。

建立模型

以上的關鍵路徑可以用一個數學模型表示。

X: 快取再次被使用的比例（cache hit ratio）
K: 關鍵路徑上可以被快取的物件比例
N: 關鍵路徑的網路延遲
C: 關鍵路徑上的計算延遲
f(x): N 和 C 有重疊的時間（極少數狀況剛好Ｎ和Ｃ並行，通常忽略）

關鍵路徑上的物件導致網路延遲的機率（Pr）：
1−Pr(可快取)·Pr(快取可再利用|可快取)
預期的單頁載入時間（E）可以表示成：
E[X]=C+(1−K·X)·N−f(X)

有沒有很神奇！

估計模型

首先來看Ｎ和Ｃ，我們用以下這張圖的數據來估算：

comp 數字越大代表 CPU 越慢，可以發現 CPU 越差單頁載入時間越長，滿合理的。
再來 x 軸是網路速度，速度越慢載入時間越長，也很合理。

再來是Ｋ，一般而言有 65％的物件可以被快取，但只有 20％的物件會再次被使用。所以Ｋ就是 0.2。

f(X)通常可以極小，所以在模型中我們可以忽視。

至於Ｘ則是我們的操縱變因，也是整個命題的核心，究竟 Cache 到底有沒有效？

實驗

有了模型之後，當然就是做實驗啊！

Web Page Replay(WPR) 是一個紀錄連線一個 URL 所有 request 和 reponse 的裝置，這個東西的目的是製造一個穩定的假想連線。使用方式就是我先用 WPR 連一個網站，記下所有流程，之後實驗都用 WPR 的紀錄來測試。

而 telemetry 就是一個記錄時間的軟體，藉由 WPR 的紀錄來對桌面以及行動裝置的瀏覽器做測試。

實驗結果

測試數據中超過 90% 的網頁可以有超過 90%的物件被快取。理論上這麼高的比例，如果讓快取量增加，速度應該更快吧，因為網路時間是一大因子。

但結果很不幸：

我們可以看到 20% 跟 30% 快取量的載入時間竟然一樣。這邊 30% 有被控制必定包含 20% 的快取。
完全打破我們的想像。

再來看如果是「完美」的 Cache 情況下呢？

縱軸是所有測試的網站所佔的比例，橫軸是縮短時間比例。結果就如同本文開頭說的，桌面版進步 34％，行動版卻只有 13％。

同一張圖還有另外兩個實驗，我們將桌面的 CPU 和 RAM 被限制。
結果我們發現 RAM 被限制不影響結果。
但被限制的 CPU 卻非常接近行動裝置的實驗結果。

於是我們再來看這張圖：

CPU 越慢真的導致單頁載入時間變慢。如同先前假設的。

如果我們讓 Cache 增加 10%看看結果呢？

不幸的，單頁載入速度只快了 1%。證明說 Cache 幾乎不會影響。

這時候我們回到我們一開始的數學模型，Ｘ代表關鍵路徑的快取再次被利用的機率，而實驗也證明模型是有道理的，快取量增加對關鍵路徑上的物件影響微乎其微。自然時間也不會縮短。

E[X]=C+(1−K·X)·N−f(X)：Ｘ非常小的話，那麼(1-K·X) 幾乎還是 1。

結論

所以為什麼 Cache 沒效呢？

我們的模型是 E[X]=C+(1−K·X)·N−f(X)，注意這邊Ｃ(CPU)和Ｘ(Cache)同時影響了這條式子。當Ｃ的影響被放大的時候，Ｘ的影響就會被弱化。這也是為什麼桌面版瀏覽器有明顯進步，行動版卻沒有。其實行動版的 Cache 也有貢獻，只是被 CPU 吃掉了。

此外 Cache 也不見得一定有幫助，我們在乎的是「關鍵路徑」，要是路徑數量很多，Cache 被平分到各個路徑上，那麼關鍵路徑受惠的程度也就很小。

最後就是 CPU 的技術日新月異，那未來的話，如何讓 Cache 更有效就會是關鍵了！

後記：
這篇用的手機時脈很低，而最新的 iPhone A11 時脈逼近 Macbook Pro 了，在最高效能的情況下，CPU 的影響因子可用又會變小，那這邊的結論就會截然不同。所以可以說這篇的結論是用「中階」款手機，也就是一般市面上的普遍狀況。

希望有幫到大家，大家明天見！

關於作者

劉安齊

軟體工程師，熱愛寫程式，更喜歡推廣程式讓更多人學會

• 個人網站
• Github
• FB粉專--微中子